Week27 - 從 gPRC 一路探討Go-Micro, Docker, Kubernates, Istio 的愛恨情仇 [Server的終局之戰系列]

w3hexschool istio kubernetes docker microservice

髒桶子 York Lin 2020-08-30 20:19:07 ‧ 3550 瀏覽

分享至

本文章同時發佈於：

大家好，最近與夥伴們想導入 gRPC 這個技術來讓微服務的溝通介面更加穩定，但 gRPC 使用的協定是基於 HTTP/2 的，有些語言是只支援 HTTP/1.1 的，所以需要透過 Envoy 把 HTTP/1.1 轉換成 HTTP/2。

不過這篇文章不是要探討 gRPC XD，而是探討以 Envoy 來架構的 Istio 對現代微服務架構的影響。

如果試著去 Google 搜尋一下 Envoy，馬上就會搜尋到 Istio，而 Istio 的用途是為了解決 Kubernetes 上的各種Service Mesh問題，官網是這樣說的：

Its requirements can include discovery(服務發現), load balancing(負載平衡), failure recovery(故障恢復), metrics(指標), and monitoring(監控).

我與夥伴們最近也有在研究 Go-Micro 這樣的微服務框架，在ITNEXT: Go-Micro Tutorial的教學系列文章中，會發現 discovery, load balancing, failure recovery 等等以上專有名詞也提了不少次。

這時候我們的疑惑就來了：

問題 1: Istio 跟 Go-Micro 是同樣類型的東西嗎？
問題 2: Istio 如果跟 Go-Micro 是同樣類型，那他怎麼又常常與不同層次的 Kubernetes 一起討論呢？

這篇文章會以這樣的角度出發，如果你跟我一樣在微服務框架與Istio所負責的職責中迷惘，希望可以解決你的困惑。

並且也歡迎各個大神教導指正本文的想法，謝謝～

先說結論再來細講：

廣義上，管理各個微服務，Go-Micro 是在軟體層，而 Istio 是在平台層

一開始的微服務

在 Docker 才剛帶領微服務快速發展的時候，很多微服務的管理與溝通，都是在 Code 這個軟體層完成，以 Go-Micro 來舉例:

Service 要怎麼知道彼此的位置: 可透過 etcd 的 discovery 來完成。教學文在此
Service 的流量太大要管控怎麼辦: 可透過 Go-Micro 的 Rate-Limiter 來限制。教學文在此

這些功能你現在去查 Kubernetes，會發現其實也有類似的功能，為什麼要在 Code 裡實作一套卻又在平台實作一套呢？原因其實很簡單：

在那個時候 Kubernetes 還處於與 OpenShift, Docker Swarm 四處奔殺的戰國時代，容器管理的平台的發展還不完全，這些功能他們還不在行。

所以各個社群單純就以以下方式建構微服務:

Docker 來打包 Service
容器管理的平台單純就只是部署容器
Service 的溝通與管理全部透過 Code 來完成

逐漸進化的微服務

後來 Kubernetes 在容器管理大戰勝出後，就開始妥善的完善其功能，比如說 discovery, load balancing, failure recovery 等等，所以這時候尷尬的點就來了，

Code 實作的微服務溝通與管理的功能，Kubernetes 也可以辦到

所以大家就開始把 Code 的功能丟到 Kubernets 來處理，以 load balancing 來說，改用 Kubernets 可以:

避免被特定語言的微服務框架綁住，例如用 Golang 的 Go-Micro, Java 的 Spring-Cloud 等等都要配合他們所屬的語言生態系
可以很好的與 AWS, GCP, Azure 的 load balancing 結合
Service 只掌管業務邏輯，而這些溝通與管理的功能就交給平台，職責更加清晰

於是微服務的溝通與管理就從軟體層移到了平台層上。

平台層大爆炸的救世主 - Istio

當大家把很多 Code 處理的微服務相關事項移到平台層上後，發現

Damn! 好像 Kubernets 也不是能全部的微服務溝通都解決掉啊

舉個簡單的例子:

以往在 Code 裡 Service A 呼叫 Service B 假設超時，只要透過 Go-Micro 的 Hystrix 來斷線即可，現在換成了 Kubernets 那該怎麼辦？

大家把這些麻煩的微服務溝通問題稱作Service Mesh，Kubernets 本質是個容器管理平台，這些溝通問題就得交給另一個角色，即是Istio。

而要可以不入侵 Code，又要可以處理Service 的溝通問題要怎麼做呢？Istio 想到一個有趣的做法，

Sidecar - 在每個 Service 旁都增加一個 Envoy Proxy 來掌握所有溝通

如圖所示，每個藍色圖標的 Service 旁邊都會跟著一個粉紅色圖標的 Envoy Proxy，每個 Service 發出去與接收的流量，都要透過他轉送(就是~~妻管嚴的意思~~)，如此一來就可以管理所有微服務的溝通。

有了 Envoy Proxy 來統一溝通介面，Istio 就可以依照這個界面透過 kiali, jaeger 等專業的 Service Mesh Tool 來輔助。

結論

回到原本的問題:

問題 1 解答: Istio 跟 Go-Micro 所屬的層次不同，但都有負責解決微服務溝通的職責
問題 2 解答: Istio 跟 Go-Micro 都有解決微服務溝通的職責，但 Istio 是非常完好的與 Kubernetes 結合的，因為他們都是平台層的東西

而我個人傾向於將這些微服務的溝通與管理交給平台層，而業務邏輯交給軟體層的 Service，更清晰的分層。

這樣的思維導致再见，micro: 迁移 go-micro 到纯 gRPC 框架這樣的文章產生，每個 Service 只要知道其他 Service 怎麼呼叫與回應，所以 Service 只需要有統一回應與呼叫介面的 gRPC，其他 Service Mesh 的問題就交給 Istio 吧！不要大家全攪和在 Code 裡。

不過在市場上很多產品都已經頭洗一半了，要換架構消耗的成本極大，像我與夥伴們做的一些 API-Gateway 就是透過 Code 管理而非平台，這幾天使用 Istio + Kubernetes 管理 API-Gateway 也讓我體會到這些 Service Mesh 的問題的確交給平台層解決也是很不錯的選擇。

而你是怎麼認為的呢？歡迎分享討論指正，謝謝你的閱讀～